The bug

stdin end/close now trigger _onstdinclose → this.close() synchronously (packages/server/src/server/stdio.ts:76-85, registered at :100-101). close() flips _closed — so every subsequent send() rejects with StdioServerTransport is closed — and fires onclose, which Protocol._onclose (packages/core-internal/src/shared/protocol.ts:825-854) turns into an abort of every in-flight request handler's AbortController with SdkError: Connection closed. A handler that completes after abort also returns without sending its response (the post-abort check around protocol.ts:1102-1105).

But stdin EOF only closes the read direction. On a half-closed pipe the client is still reading the server's stdout, which remains fully writable — and responses to requests whose bytes arrived before EOF are still owed. The PR hard-closes the write side the instant the read side ends.

Step-by-step proof

1. A client pipelines its final request and half-closes — e.g. cat requests.jsonl | mcp-server > responses.jsonl, a one-shot smoke test, or any scripted client that writes tools/call (id 2), calls child.stdin.end(), and keeps reading stdout to EOF.
2. Node emits 'data' with the final line; _ondata → onmessage → Protocol._onrequest starts the tool handler. The handler hits its first real await and suspends; its continuation is a promise microtask.
3. The stream emits 'end' from the process.nextTick queue right behind that last 'data' — and nextTick drains before promise microtasks. So _onstdinclose → close() runs while the handler is still in flight. This ordering is deterministic, not a rare race: any handler that awaits anything (a timer, I/O, an LLM call — i.e. every real tool) loses.
4. Protocol._onclose aborts the handler's signal (ConnectionClosed). Whether the handler bails on the abort or runs to completion, its response is never written: the post-abort guard suppresses it, and even without that, transport.send() now rejects because _closed is set.
5. The client, reading stdout until EOF per normal half-close semantics, never receives the id:2 response for a request the server accepted.

This was verified empirically at PR head (049610c) with real spawned pipes and the real McpServer + StdioServerTransport: with the PR's listeners attached, a pipelined tools/call whose handler awaits 150ms observes ctx.mcpReq.signal.aborted === true and its response never reaches the parent; a control run identical except with the two 'end'/'close' registrations detached (pre-PR behavior) delivers the response. So this is a regression opened by this PR for a pattern that previously worked, not a pre-existing limitation.

Why the PR's own reasoning and test don't cover this

• The PR's no-opt-out rationale — 'once stdin has ended an open transport has nothing left to transport' — overlooks the write direction: it still has the responses to already-delivered requests to transport. The suggested escape hatch ('servers can finish in-flight work in their onclose handler') cannot work for responses, because by the time user onclose code runs, send() already rejects and the handlers have already been aborted.
• The unit test 'should still deliver messages that arrived before stdin ended' asserts delivery to onmessage only — the response round-trip is exactly the part that breaks. Arguably the current behavior is the worst combination: the pre-EOF request's side effects run (or start running), while its response is guaranteed to be dropped.
• Notably, this PR itself holds the opposite invariant one layer up: serveStdio's probe-discard path is documented as 'a probe request the entry accepted must never go silently unanswered' and implements bounded drain machinery for it (StdioConnectionChannel._pendingRequests / whenRequestsAnswered / DISCARD_ANSWER_TIMEOUT_MS in packages/server/src/server/serveStdio.ts). The transport-level EOF close violates that same invariant for every pre-EOF request.

Addressing the refutation (spec + cross-SDK)

One verifier argued this is intentional, spec-anchored behavior. Two responses:

• Spec: the stdio binding says servers 'SHOULD exit promptly when their standard input is closed', and the lifecycle doc has the client initiate shutdown by closing stdin. Neither licenses discarding responses to requests the server already accepted — a bounded drain-then-exit (flush answers to pre-EOF requests, then close) is equally 'prompt' and is the universal Unix filter/half-close convention. The shutdown sequence ('close stdin, then wait for the server to exit') is in fact more compatible with drain-then-exit than with abort-and-drop.
• python-sdk parity: the refutation claims python-sdk also cancels in-flight handlers on stdin EOF; another verifier traced the opposite (anyio task group waits for in-flight handler tasks while the stdout writer stays open). The two readings conflict and I could not independently resolve them here, so I don't rest the finding on parity in either direction. What is not in dispute is the TS-side A/B result: within this SDK, this PR converts a working response-delivery path into a silent drop.

Impact and fix

Any batch/one-shot stdio usage — shell pipelines, CI smoke tests, scripted clients that pipeline their last request before half-closing — silently loses the final response(s) while the request's side effects still execute. The failure is silent on both sides: the server sees only an aborted signal and a swallowed send() rejection; the client just sees stdout EOF without the answer.

Fix shape: on stdin 'end', stop reading and begin a graceful drain instead of an immediate hard close — defer close() (and hence onclose/handler abort) until requests delivered before EOF have been answered, bounded by a timeout as a backstop, mirroring what whenRequestsAnswered already does in this PR's serveStdio channel. Alternatively, at minimum document that half-closed batch usage is unsupported — but given the pattern worked before this PR, draining is the better outcome.